home *** CD-ROM | disk | FTP | other *** search
/ The Original Shareware 1.1 / The Original Shareware (WeMake CDs)(Volume 1.1)(CDs, Inc)(1993).iso / 16 / fpc225_3.zip / F-PCHELP.ZIP / INTERNAL.TXT < prev    next >
Text File  |  1988-06-03  |  3KB  |  48 lines
  1. \ INTERNAL.TXT  Documentation on the internals of F-PC   by Tom Zimmer
  2.  
  3.  
  4.   F-PC is my (Tom Zimmer) latest Forth system of the month. F-PC was built
  5. to handle a class of programming problems that cannot be handled well
  6. on any normal implimentation of Forth because of space constraints.
  7.  
  8.   F-PC allows the LIST (colon space) segment to be much larger than in
  9. any of my previous Forths.  Strings have also been moved out of
  10. CODE space back into LIST space, which means there is effectively
  11. unlimited space for text messages.  In fact the only real limitation
  12. in size comes from the fact that there are only 64k available for
  13. HEADs.  My calculations indicate there is room for about 3300
  14. definitions on top of the current system of about 2000 words.  This
  15. calculation is based on an average name length of 5 characters, with
  16. an average header length of 12 bytes.  With 5300 total definitions,
  17. less than 30k of CODE space would be used for CODE FIELDS of colon
  18. definitions, leaving the remaining 30+k of CODE space for variables
  19. and arrays.  Not an infinitely large application obviously but
  20. probably large enough for most (99%) applications.
  21.  
  22.   F-PC places a segment (ES) and and offset (IP) on the return stack
  23. for each nest operation. Only the starting RELATIVE segment is
  24. compiled into the CODE FIELD, and the conversion to absolute segment
  25. is performed by NEST.  This makes the code fully relocatable as is
  26. required by the DOS environment.  Some performance could be gained by
  27. using absolute segment addressing, and performing a conversion at
  28. save and load time to and from relative and absolute, but I have not
  29. done this, and don't plan to for now.  The performance gain would
  30. come from having a simpler NEST, what would not need to perform the
  31. relative to absolute conversion at runtime.  This system looses about
  32. 20% in nest/unnest performance due exclusively to that conversion.
  33.  
  34.   CS and DS always point to the CODE space, and so all assembly
  35. language operations work with data in the CODE segment unless a
  36. special operator like @L or !L is used to reach an external memory
  37. area.  This means there is no penalty to be paid for most Forth
  38. operations.
  39.  
  40.  05/19/88 22:03
  41.         Fixed a potentially dangerous bug in FSAVE, there was only
  42.         32 bytes of stack space allocated in the .EXE file to be
  43.         available at boot time, and under some conditions some of
  44.         the code was getting over written. I have changed the
  45.         allocation to be 255 bytes. This seems to work OK!
  46.  
  47.  
  48.